maybe? otherwise it's less clear what kind of thing we're doing

is there really no good way to do shallow equality here? seems awkward to destructure config just to pass it back in again "re-structed", as it were

nope :/ could wrap it into a hook but it adds an extra layer of execution that seems worse

i feel like it'd be a useful hook! we'd use it in react-relay-mutation at least...

added!

arg i need to handle the teardown manually i think this will fire too often

yeah, what you want to do is:

const dependenciesRef = useRef();
dependenciesRef.current = dependencies;

const cleanupRef = useRef(null);

useEffect(() => {
  if (cleanupRef.current === null) {
    const cleanup = effect();

    cleanupRef.current = () => {
      if (isEqual(dependenciesRef.current, dependencies)) {
        return;
      }

      cleanupRef.current = null;
      cleanup();
    };
  }

  return cleanupRef.current;
});

e.g. dependenciesRef.current there is already the new value, while dependencies as bound in cleanupRef.current is still the old value

nvm i see what you did, very clever

yeah, i think it's the only way to do this without fully emulating everything ourselves

though, it's probably a good idea to pass in the "raw" dependencies list to the base effect fn

what's the point of this overload? it looks like you're parametrizing on TDeps in all cases. so i don't see what could satisfy this overload but not e.g. the main fn defn below?

yeah, what you want to do is:

const dependenciesRef = useRef();
dependenciesRef.current = dependencies;

const cleanupRef = useRef(null);

useEffect(() => {
  if (cleanupRef.current === null) {
    const cleanup = effect();

    cleanupRef.current = () => {
      if (isEqual(dependenciesRef.current, dependencies)) {
        return;
      }

      cleanupRef.current = null;
      cleanup();
    };
  }

  return cleanupRef.current;
});

you probably want "shallow equal" for the config.

actually we probably want a helper that does "shallow equal for each member of deps array"

e.g. dependenciesRef.current there is already the new value, while dependencies as bound in cleanupRef.current is still the old value

this typing seems odd to me. DependencyList is typed as ReadonlyArray<any>... but realistically we're going to have something like a tuple type. do tuple types extend read-only arrays of type any?

... apparently so, but it's weird

not sure why the overloads are needed at all... seems like anything that would pass validation for the overloads would pass validation here?

Overloads here are mostly for documentation not safety, yes this would be fine by itself but i think the intellisense is usually nicer to read with overloads

don't you need this here? not that there can really be an element on immediate mount